Database schemas are collections of objects such as
tables, views, and procedures that enable a powerful way to manage
permissions. As demonstrated in the AdventureWorks2008 database,
schemas have been set up for business areas such as Human Resources,
Sales, and Purchasing. Although all the objects associated with each
business area are contained within the same database, the objects are
logically grouped within the respective schemas, enabling greater
control through permissions. As seen in the User section, one schema or
multiple schemas can be granted
to a user making it unnecessary to permission each object individual to
the user. The user is limited to the schemas to which they have been
granted access, preventing a user from being able to access objects
owned by another user. Schemas must be transferred to a different user
or role if the schema owner needs to be deleted.
1. Add a New User
|
You
need to explicitly add a SQL Server Login to the AdventureWorks2008
database so that a user can select data from all the user tables in the
Sales schema.
In the SQL Server Management Studio, locate the Users folder in the Security folder for the AdventureWorks2008 database. Right-click on the Users folder and select New User from the menu. In the Database User – New window, you will be mapping your Login to create this new user, so enter your instancename\your name in the User name text box. Browse to your Login to complete the Login name text box. Select the Sales schema as the Default schema. Select Sales in the Owned Schemas section. Select db_datareader in the Role Members section. Your window should look similar to Figure 1.
Click OK. Your newly created user will appear in the Users folder.
|
Users versus Logins
We
have already touched on the definition of both Users and Principals. We
will now take a look at Logins and how they relate to users and other
instance and database securables.
When
you are setting up users and logins it is important to distinguish
between Authentication: identifying users and determining if they are
who they say they are, and Authorization: what level of access should
the user have, what permissions do they have, and to which resources do
they have access.
Logins
are created at the instance level and can be mapped to a Windows user
account, a domain account, a Windows group, a domain group, or an
isolated login contained within SQL Server. Setting up a SQL Server
Login provides a user access to the SQL Server instance. While setting
up a login, you can provide access to one or more databases. Logins do
not provide access to the objects contained within the database.
Permissions to access database objects are at the database user level.
When
the SQL Server instance has been set up to use Windows Authentication
mode, referred to as “integrated security,” mapping a Windows account,
group or domain account, or group to a login enables a Windows user to
login into SQL Server using their Windows credentials. They do not need
a separate SQL Server Login. If a SQL Server specific login has been
created when the SQL Server instance has been set up to use mixed mode
authentication, the Windows user will need to log in into their Windows
account and then be prompted to enter their SQL Server user name and
password when accessing SQL Server. This can be a nightmare for both
the DBA and user if attempting to keep Windows and SQL Server Logins in
sync. SQL Server logins cannot not be used if the server is using the
Windows Authentication mode.
Mapping
the Windows account, group or domain account, or group to a SQL Server
login will eliminate multiple logins since SQL Server will validate the
user by checking their Windows credentials. Maintenance of user
passwords is done within Windows and if mapping groups to a login, the
adding and deleting of users from the group is transparent to the DBA.
An example of logins can be seen in Figure 2.
2. Create a SQL Server Login
|
You
need to add a new SQL Server Login and it will be mapped to a domain
account and be set up to access the AdventureWorks2008 database.
In the SQL Server Management Studio, locate the security folder at the instance level. Under the security folder you will see a folder named Logins. Right-click on Logins and select New Login from the menu. In
the “Login – New” window in the general section locate the domain
account that you need to map to the login. Make sure that Windows
authentication is selected. For the Default Database, select AdventureWorks2008. Now switch sections and select User Mapping. In the User Mapping section, locate AdventureWorks2008 in the “Users mapped to this login” section and check the Map column. Your entries should look similar to Figure 3 and Figure 4.
Click on OK and you have completed creating a new SQL Server login.
|
Authentication Mode
When
you are installing SQL Server 2008, the selection of an authentication
mode for the database engine is required. The choices are either
Windows authentication or mixed mode authentication.
If
you select the Windows authentication mode, SQL Server authentication
will be disabled. Selecting mixed mode authentication enables both
Windows and SQL Server authentication. You cannot disable Windows
authentication.
When
selecting mixed mode authentication you are required to establish a
strong password for the sa account. If you selected Windows
authentication, the sa account will be created but disabled. It is
important to remember this because if you change authentication modes
at a later time, you will need to enable this account and establish a
password at that point if you wish to use this account.
Changing
the authentication mode can be done at anytime but it does require that
you restart SQL Server. You can change the authentication mode by right
clicking on the server in the SQL Server Management Studio and the
change can be made under security in the Server Authentication section.
See Figure 5.
Using
Windows Authentication (integrated security) is recommended and
considered to be more secure than using SQL Server logins or mixed
mode. Windows accounts are subject to the built-in security features in
Windows and are sometimes considered to be Trusted connections to SQL
Server since Windows handles the authentication.
If
you are using mixed mode, Any SQL Server Logins created that are not
based on Windows user accounts are required to follow strong password
guidelines. Database users using SQL Server logins will need to login
using a user name and password every time they connect.
SQL Server logins offer the following password policies:
User must change password at next login – Established in the Log-in properties in the SQL Server Management Studio.
Enforce Password Expiration – Based on the maximum password age policy of the computer.
Enforce
Password Policy – SQL Server enforces Windows password policies
established on the computer. This is only available in Windows 2003
Server and later.
When
you are establishing using SQL Serving authentication, it is important
to be aware of the disadvantages and advantages. Here are some of the
disadvantages:
A
Windows domain user who has a Windows user id and password will have to
also enter their SQL Server user id and password. The user will have to
present the SQL Server credentials every time they connect, and
maintaining multiple user ids and passwords can be troublesome for
users.
SQL Server Logins cannot not take advantage of the Kerberos security protocol that is used by Windows.
SQL Server Logins cannot offer many of the additional Windows password policies.
Here are some of the advantages:
SQL Server can support older applications that require the use of SQL Server Logins.
Users
in an environment of mixed operating systems where users are not
authenticated by a Windows domain can connect to SQL Server.
Users can connect from unknown or untrusted domains.
Users can connect when creating their own identities in Web-based applications.
Software developers can distribute applications based on specific SQL Server Logins.
3. Change the Authentication Mode
You
selected mixed mode authentication when you installed SQL Server 2008.
You have done some research and have found that none of the
applications connected to SQL Server are depending on SQL Server Logins
so you want to make your environment more secure and have decided to
switch the Authentication Mode to Windows Authentication exclusively.
In the SQL Server Management Studio, right-click on the server and select Properties from the menu.
In the Security Authentication section of the screen, select Windows Authentication. Your screen should look like Figure 6.
Click on OK to save the change.
